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Dear Sir: 

Appellant requests review of the rejection in the above-identified application Claims 1-80 remain 
pending in the application. Claims 1-17 and 56-80 have been withdrawn. Claims 18-55 stand finally 



Examiner rejected claims 18-55 under 35 U.S.C. § 102(e) as being anticipated by Conallen 
("Building Web Applications with UML", Second Edition, October 10, 2002). The following clear 
errors are noted in Examiner's rejection. 



1. Conallen is not prior art under § 102(e). Conallen is not a patent or published patent 
application. Therefore, the rejection under § 102(e) is improper. 

2. Conallen is clearly directed at Web applications and not at Web Services . On p. 3, 

1st paragraph, Conallen states "this book is about building model-driven Web applications ." The term 
Web Services is well known in the art, and one of ordinary skill in the art would recognize the difference 
between "Web Services" and "Web applications." The background section of the instant application 
provides an extensive discussion of Web Services. Conallen clearly defines Web applications "for the 
purpose of this book" in the paragraph beginning on p. 9 and extending onto p. 10. Conallen does briefly 
discuss Web Services on pp. 63-68, in a section titled "Web Services" that appears in Chapter 4, titled 
"Beyond HTTP and HTML," which begins on p. 49. Conallen makes clear the distinction between Web 
Services and Web applications in the 3rd paragraph on p. 63: "The term Web Services is the latest hot 
phrase in development circles. Although the term has the word Web in it, it is not a Web application- 
specific technology . Instead, it uses Web technologies, such as Web servers and HTTP, to provide a set 
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rejected. 



Claim 18 



of services that can be invoked by other programs on the network." Thus, both Conallen and Appellant's 
specification are consistent in distinguishing Web Services from Web applications. Most of Conallen 
cited by Examiner pertains to Web applications, not Web Services. Nowhere does Conallen extend the 
notions presented in his book to generating integrated Web Service architectures . Again, Conallen clearly 
states "this book is about building model-driven Web applications ." Conallen' s discussion of Web 
Services is simply an aside "discuss[ing] the limitations and extensions to... two principal elements of 
Web applications: HTTP and HTML" (p. 49, 2nd paragraph). 

In the response in the Action dated August 19, 2008, Examiner asserts Conallen "does not 
seem to stop short in just building a web application but intended for a service, i.e. Web service, as per 
pages 63-68." Conallen's discussion on pp. 63-68 is an aside "discuss[ing] the limitations and extensions 
to... two principal elements of Web applications." On p. 3, 1st paragraph, Conallen states "this book is 
about building model-driven Web applications ." Conallen specifically states, in the 3rd paragraph on p. 
63: "Although [Web Services] has the word Web in it, it is not a Web application-specific technology ." 
Moreover, on p. 68, Conallen actually states "Although this book is not directly devoted to an 
exploration of how to build Web services, it is hoped that an understanding of the issues involved in 
building Web applications can be applied to the building of scalable, robust Web services." Again, 
Conallen clearly differentiates between Web services and Web applications, and clearly states that the 
book is not directed at a method or tool for building Web services. Conallen clearly does not teach 
or suggest that his system of "building model-driven Web applications " could be used to build Web 
services; Conallen clearly indicates on p. 68 that his teachings are not sufficient for such a purpose. 

3. Conallen does not anticipate a system for generating a vendor-independent Web 
Service architecture. Examiner cites Conallen, p. 65, and states "using UDDI, a standard for publishing 
and describing Web services." Conallen does not extend the notions presented in his book to generating a 
vendor-independent Web Service architecture. Moreover, UDDI is not a system for generating a vendor- 
independent Web service architecture; UDDI is simply a mechanism that may be used with Web service 
architectures. On p. 65, Conallen states that UDDI is "a mechanism for publishing and describing Web 
services to potential clients." On p. 66, Conallen states the "general usage scenario [for UDDI] is for a 
programmer to use a Web-based interface or specialized tool to query the UDDI registry via its inquiry 
API," and goes on to state "This information described in a UDDI business service... categorizes and 
points to URLs that describe Web services but doesn't provide enough detail for a programmer to 
code a system that can accept and send SOAP-based Web service messages." 

4. Conallen does not anticipate a system for generating a vendor-independent Web 
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Service architecture comprising a plurality of heterogeneous components. Examiner cites p. 425, "web 
server is most likely a commodity component, such as Tomcat, WebSphere, WebLogic and IIS." P. 425 
appears in Appendix D, which discusses a "master template mechanism" in which "one p. template (JSP) 
is used for all outgoing pages, thereby helping enforce a consistent user interface look-and-feel" is clearly 
directed at Conallen's goal of "building model-driven Web applications." Appendix D is directed at Web 
applications, not Web services. Conallen does not extend the notions presented in his book to generating 
a vendor-independent Web Service architecture comprising a plurality of heterogeneous components. 
Moreover, pages 65 and 425 are from completely different and distinct sections of the Conallen reference 
directed at different technologies, and thus the Examiner is erroneously attempting to combine the 
disparate citations in a manner not described in the reference. 

5. Conallen does not anticipate means for generating one or more Use Cases for the Web 
Service in accordance with one or more design patterns. The citations provided by Examiner disclose 
various Web application use cases. On p. 173, at the beginning of a section titled "Use Cases", Conallen 
actually states: "Because a full discussion of use cases is beyond the scope of this book, I will concentrate 
on the highlights and more interesting points as they relate specifically to Web-based applications ." 
Furthermore, nowhere does Conallen disclose means for generating one or more Use Cases for the Web 
Service in accordance with one or more design patterns. In fact, Conallen does not even disclose means 
for generating one or more Use Cases in accordance with one or more design patterns in reference to the 
Web application-specific Use Cases Conallen does discuss. 

6. Conallen does not anticipate means for generating a high-level architecture for the 
Web Service in accordance with the one or more design patterns. Examiner cites Conallen, Fig. 8-4 on 
p. 176 and Fig. 8-7 on p. 181, which appear in a section titled "Use Cases" that begins on p. 173, which 
concentrates on "...[use cases] as they relate specifically to Web-based applications ." The citations 
describe Web application use cases. Furthermore, on p. 178, Conallen states "The complete collection of 
use cases, actors, and diagrams form a use case model, which, like individual use cases, is just one part of 
the system's requirement specification ." Thus, what Conallen describes in this section is not even 
sufficient to be classified as a high-level architecture for a Web application, much less for a Web 
service. Moreover, nothing in these citations teaches means for generating a high-level architecture for 
a Web Service in accordance with one or more design patterns. 

7. Conallen does not anticipate wherein the high-level architecture identifies two or 
more entities of the Web Service. Examiner cites Fig. D-3 on p. 425, "main analysis of class diagram in 
screen components"; p 438: "entity tier and data tier." Fig. D-3 shows a class diagram for a Web 
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application, and p. 438 describes an Entity Tier and Data Tier for a Web application; neither citation 
teaches or suggests entities of a Web Service . The citations clearly appear in portions of Conallen 
directed at Web applications, not at Web services. Furthermore, Examiner previously cited Fig. 8-4 on p. 
176: "top level use case diagram," as equivalent to Appellant's "high-level architecture." What Conallen 
describes on p 173 clearly does not identify what is illustrated and described on p. 425 and p. 438. 

8. Conallen does not anticipate wherein the high-level architecture identifies two or 
more entities of the Web Service and the relationships and interactions among the entities . Examiner 
cites p. 177: "relationship between use cases." This citation appears in a distinctly different section of 
Conallen and appears to have little or nothing to do with the citations relied upon by Examiner as teaching 
"entities" (Figure D-3 on p. 425, and p. 438). Neither Figure D-3 nor p. 438 directly address or illustrate 
use cases. Moreover, "use cases" are not themselves properly entities, and certainly would not be 
considered entities of a Web Service. 

9. Conallen does not anticipate means for generating a logical architecture for the Weh 
Service according to the use case scenarios and in accordance with the one or more design patterns, 
wherein the logical architecture identifies two or more logical components of the Weh Service and the 
relationship among the logical components, and wherein the logical architecture comprises two or 
more layers. Examiner provides several citations that all appear in a section titled "Web Application 
Extensions for UML" that begins on p. 236. The section is clearly directed at Web applications, and is 
not directed at Web services. Moreover, the section in which the Examiner's citations appear simply 
describes "the logical view of a UML model", and does not teach the limitations as recited in claim 18. 

10. Conallen clearly does not anticipate Appellant's claim 18. Nowhere does Conallen 
disclose "each and every element of the claimed invention" as arranged in the claim. Moreover, 
Examiner has improperly cited portions of Conallen from various chapters, sections, and appendices, 
some of which are not directly related, in an attempt to assert that Conallen anticipates claim 18. For 
example, Examiner has cited Fig. 8-4 and p. 177 from a section "Use Cases", citations from a section 
titled "Web Application Extensions for UML", Fig. D-3 in Appendix D, and p. 438 from Appendix E. 

Claim 20 

Conallen does not anticipate Appellant's claim 20 for at least the reasons 1-10 given above 
in regard to claim 18. In addition, Conallen does not anticipate implementing a Web Service 
according to a Web Service architecture. Examiner cites pp. 9-10 and Fig. 2-1: "build Web application 
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based a basic web system on a Web Server." Appellant cannot identify the quote from the Examiner on 
the cited pages. However, Fig. 2-1 illustrates a "Basic Web system," which is clearly not a Web service. 
Furthermore, the discussion on pp. 9-10 is directed at Web applications . Again, Conallen makes clear the 
distinction between Web Services and Web applications, for example in the 3 rd paragraph on p. 63: "The 
term Web Services is the latest hot phrase in development circles. Although the term has the word Web 
in it, it is not a Web application-specific technology ." Moreover, on p. 68, Conallen actually states 
"Although this book is not directly devoted to an exploration of how to build Web services, it is hoped 
that an understanding of the issues involved in building Web applications can be applied to the building 
of scalable, robust Web services." Conallen actually states that the book is not directed at building Web 
services ; Conallen clearly indicates that his teachings are not sufficient for such a purpose. Conallen does 
not anticipate a method for generating a Web service architecture at all, and Conallen clearly does not 
anticipate implementing a Web Service according to a generated Web Service architecture. 

Claim 38 

Claim 38 recites a computer-accessible storage medium including program instructions that are 
computer-executable to implement the method described above regarding claim 20. The rejection of 
claim 38 is not substantially different than the rejection of claim 20. Therefore, Appellant traverses the 
rejection of claim 38 for at least the reasons presented above in regards to claim 20. 

In light of the foregoing remarks, Appellant submits the application is in condition for allowance, 
and notice to that effect is respectfully requested. If any extension of time (under 37 C.F.R. § 1.136) is 
necessary to prevent the above referenced application from becoming abandoned, Appellant hereby 
petitions for such an extension. If any fees are due, the Commissioner is authorized to charge said fees to 
Meyertons, Hood, Kivlin, Kowert & Goetzel PC Deposit Account No. 501 505/568 1-66300/RCK. 

Respectfully submitted, 

/Robert C. Kowert/ 

Robert C. Kowert, Reg. #39,255 
ATTORNEY FOR APPLICANT(S) 

Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8850 

Date: October 20. 2008 
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